Celestin Apprentice 2

home *** CD-ROM | disk | FTP | other *** search

/ Celestin Apprentice 2 / Apprentice-Release2.iso / Information / Digests / CSMP Digest / volume 1 / csmp-v1-150.txt < prev next >

Wrap

Text File | 1994-12-08 | 43.5 KB | 1,064 lines | [TEXT/R*ch]

C.S.M.P. Digest Sun, 02 Aug 92 Volume 1 : Issue 150 Today's Topics: Emulating TrueType Sending Apple events to the Finder. Light-weight processes in a Mac program need help writing a screensaver Offscreen PixMaps Apple Event problem Getting the text from a TERec The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly. The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi-ure on my part, but PostScript determines what regions to >fill by crossing windings, and since TrueType is just an enhancement to >PS I'd assume it works the same way. To determine windings, draw an >imaginary line across your object at any point, and increment the wind >count when you cross a line drawn clockwise, and decrement your count >when the line is draw counterclockwise. A positive wind count means >you are in a fill region. That is, if the outer circle is drawn >clockwise and the inner circle is drawn counterclockwise, than a >horizontal line across the 'o' would start with zero windings, cross >the first line and have one windings (so now we're filling) cross the >second line (so now we're through filling) cross the second line again >(so we're filling once more) and finally cross the first line a second >time (and we're back to our original fill status). [0 1 0 1 0] Note >that it is the change in the direction of the line crossed that is >important. That is, if the inner circle was drawn clockwise as well, >the total "winding" value would still be positive when you crossed the >second line [0 1 2 1 0] and you'd end up with a filled circle instead >of an 'o'. Or if the outer circle was wound in the opposite direction, >you would go [0 -1 -2 -1 0] and you would end up with two concentric >circles instead of an 'o' (since you are never positive and hence never >fill.) Pick up an introductory postscript book (the adobe 'cookbooks' >are excellent) for better explanations. (or browse through the stuff >thats available for ftp on adboe.com) Actually I'm trying to use a library that uses NURBS to describe surfaces and lets you pass it further NURBS curves to defines holes punched in the surfaces. Anybody got a good intro reference to NURBS? I sort of know what I'm doing on this score. I wrote an article some years ago for MacTutor on how to draw the famous "teapot" on the mac using Graf3d. It is composed of the 3-D analog of the quadratic planar bezier splines that make up true type characters. You haven't read it because MacTutor lost it before accepting it and I never got around to resubmitting it. Since I got tired of people distributing my trivial demo programs without the accompanying source code that was the _raison_d'etre_, I added a "Decompile" command to the menu which faked the THINK C "compiling' dialog running backwards, and created a mess of source files in the current directory, and also a THINK C version of the Graf3D library. The current issue of the "born-again" MacTutor has some useful demo programs for 3-D animation, and an advertorial for a 3-D shaded surface package for $250.00 (source included.) If anyone wants a copy of the 3-D teapot source code and article, mail $15.00 to Mosaic Codes Suite 2036 2140 Shattuck Ave Berkeley, CA 94704 with a note saying "I want Teapot" and I'll send yoy a Mac floppy of the whole thing. +++++++++++++++++++++++++++ From: parent@apple.com (Sean Parent) Date: 25 Jun 92 16:59:05 GMT Organization: Apple Computer, Inc. In article <1992Jun13.035121.9411@well.sf.ca.us> oster@well.sf.ca.us (David Phillip Oster) writes: > If you are interested, here is Jonathon's description of the > rasterization process: > > > >Pure conjecture on my part, but PostScript determines what regions to > >fill by crossing windings, and since TrueType is just an enhancement to > >PS I'd assume it works the same way. TrueType is not "just an enhancement to PS." It is a VERY different mechanism for rendering fonts. By convension TrueType fonts are drawn so that they can be filled using a winding number algorithm as described but the TrueType engine uses an xor algorithm when it fills. This is a simpler algorithm where the state of the fill toggles as you cross an edge. - ---------------------------------------------------------------------- Sean Parent "Quality unattainable in a reasonable amount of time." --------------------------- From: molla@paone.uucp (Levent Mollamustafaoglu) Subject: Sending Apple events to the Finder. Date: 12 Jun 92 06:41:41 GMT Organization: Aiken Computation Lab, Harvard University How can I send Apple events to the Finder itself, such as "Open Selection"? Inside Mac VI is not very clear about this. Normally for other applications I can determine the target address by using AECreateDesc and the application signature, then I can use the descriptor record in AECreateAppleEvent. But I'm confused about what to do when the target is the Finder. Any help from AE gurus is very much appreciated. =========================================================================== Dr. Levent Mollamustafaoglu Harvard University molla@paone.harvard.edu molla@metatron.harvard.edu =========================================================================== +++++++++++++++++++++++++++ From: jackl@austin.apple.com (Jack Littleton) Date: 12 Jun 92 17:34:09 GMT Organization: Apple Computer, Inc. In article <1992Jun12.064141.2357@das.harvard.edu>, molla@paone.uucp (Levent Mollamustafaoglu) writes: > > How can I send Apple events to the Finder itself, such as "Open > Selection"? Inside Mac VI is not very clear about this. Normally > for other applications I can determine the target address by using > AECreateDesc and the application signature, then I can use the > descriptor record in AECreateAppleEvent. But I'm confused about > what to do when the target is the Finder. There are several things you can do. You can still use the finder's signature, or you can use the process manager's GetNextProcess routine to loop through all processes until you find the Finder's process number, and use that for the address descriptor. How to loop through the open processes is shown in Inside Mac VI, page 29-11. Once you have the ProcessSerialNumber for the Finder, you don't need to do the loop anymore. That is, unless the Finder quits and relaunches (for whatever reason), and thus gets a new ProcessSerialNumber. If the Finder does get a new serial number, AESend will return -903, and that's your que to look for a new ProcessSerialNumber (do the loop thing again). - -- Jack Littleton Developer Tools Engineering Group Apple Computer, Inc. +++++++++++++++++++++++++++ From: prw@Apple.COM (Paul Wenker) Date: 26 Jun 92 17:50:16 GMT Organization: Apple Computer Inc., Cupertino, CA In article <27238@goofy.Apple.COM> jpugh@apple.com (Jon Pugh) writes: >In article <1992Jun12.064141.2357@das.harvard.edu>, molla@paone.uucp (Levent Mollamustafaoglu) writes: >> >> How can I send Apple events to the Finder itself, such as "Open >> Selection"? Inside Mac VI is not very clear about this. Normally >> for other applications I can determine the target address by using >> AECreateDesc and the application signature, then I can use the >> descriptor record in AECreateAppleEvent. But I'm confused about >> what to do when the target is the Finder. > >ThatUs the way to do it. > > kFinderSignature = 'MACS'; > > aSig := kFinderSignature; > err := AECreateDesc(typeApplSignature, @aSig, 4, finderAddress); > >Jon >kAERegistrar Here are some things to keep in mind when sending events to the Finder. 1) Be sure you can handle the case where the Finder isn't running. There are cases now (and there will be more in the future) where the Finder gets replaced by another shell program. 2) If you want to send an event to the current shell program, as opposed to the Finder specifically, you can loop through the existing processes looking for a process of type 'FNDR' and then use the ProcessSerialNumber of that process as your destination address. 3) If you send an event to the current shell program, be sure you handle cases where that program doesn't support some or all of the Finder's events. 4) Also, be aware that the current shell program and the Finder may both be running (i.e. there are two processes of type 'FNDR' running). It's unlikely that any replacement shell program could do everything that the Finder does, so there will probably be times when the user needs to run the Finder in addition to their shell program. - -Paul Wenker - -Apple Computer +++++++++++++++++++++++++++ From: molla@paone.uucp (Levent Mollamustafaoglu) Date: 26 Jun 92 19:16:17 GMT Organization: Aiken Computation Lab, Harvard University In article <69283@apple.Apple.COM> prw@Apple.COM (Paul Wenker) writes: > >Here are some things to keep in mind when sending events to the Finder. > >1) Be sure you can handle the case where the Finder isn't running. There >are cases now (and there will be more in the future) where the Finder gets >replaced by another shell program. > Another case to consider is when there is no shell and no Finder running. (Just add the Quit command to the Finder, launch other applications, then quit from the Finder) It seems the best way is to send the event to the Finder and deal with errors when you can not get a result. Using the process manager is also a good idea, but I would prefer to rely on the events themselves, instead of the Process Manager, which might change. Thanks for all the help. =========================================================================== Dr. Levent Mollamustafaoglu Harvard University molla@paone.harvard.edu molla@metatron.harvard.edu =========================================================================== --------------------------- From: samuel@cyklop.nada.kth.se (Samuel Cederlund) Subject: Light-weight processes in a Mac program Date: 21 Jun 92 16:34:28 GMT Organization: Royal Institute of Technology, Stockholm, Sweden I'm writing a package for light-weight processes on the mac. The code is pretty straightforward. Stacks are allocated off a global array, ie unsigned char stacks[0x4000]; I'm using MPW 3.2 and Macsbug in 7.0. Changing the stack pointer seems to break the system, however. I have managed to run the program as an MPW tool by changing to user mode in the debugger. I understand changing the stack pointer into some heap-allocated block would cause an error like "stack has grown into heap" or something similar. But global variable space? Now, if there be a compelling reason why the SP must be in the stack area, then a solution would be simply to *grow* the stack area. Can this be done? I'd gratefully appreciate any comments on the above from anybody with greater insights than myself (5 000 000 000, although I hope not all of them read this newsgroup :-)). Sam Samuel Cederlund | "When a true genius appears in the world, programming Mac | it is the sign that the dunces are all in samuel@nada.kth.se | confederacy against him." +++++++++++++++++++++++++++ From: hammett@sbsu1.aukuni.ac.nz (Tim Hammett) Date: 21 Jun 92 21:46:47 GMT Organization: University of Auckland, New Zealand. samuel@cyklop.nada.kth.se (Samuel Cederlund) writes: >I'm writing a package for light-weight processes on the mac. The code is pretty >straightforward. Stacks are allocated off a global array, ie >unsigned char stacks[0x4000]; >I'm using MPW 3.2 and Macsbug in 7.0. >Changing the stack pointer seems to break the system, however. I have managed t >run the program as an MPW tool by changing to user mode in the debugger. There are two problems with implementing threading by changing your stack pointer. First, as you have mentioned, if you put your stacks in the heap, a "stack has collided with heap" system error will probably occur. Second, some Toolbox/OS/System (not sure which) routines treat the space between A7 & the top of the heap as scratch space. This eliminates the avenue of allocating your threads' stacks on the stack. This leaves the option of implementing your threading routines by stack copying. A package which does this (although source is not available) can be found in Apple's develop magazine, issue 6 (with additional info in issue 7), and on the developer CD's. There is also some (non-Mac specific information on threading in the AT&T C++ documentation that comes with MPW C++. - -- Tim Hammett, Botany Dept, Auckland University, New Zealand. t.hammett@aukuni.ac.nz Phone: +64-9-373-7599 x8365 FAX: +64-9-373-7416 --------------------------- From: slchambe@athena.mit.edu (Stephen L Chamberlin) Subject: need help writing a screensaver Date: 21 Jun 92 20:37:51 GMT Organization: Massachusetts Institute of Technology I'm just getting started trying to write a simple screensaver which runs as a background application with System 7, and I'm having trouble figuring out how to black out the screen. There doesn't seem to be any obvious way of turning the whole screen black from a background app. The only solutions I've come up with so far are: 1. Create a new GrafPort the size of the main screen and paint it black. This doesn't work very well because the finder still redraws the icons for mounted drives on top of my nice new GrafPort, and certain other things like flashing cursors seem to poke through as well. 2. Create a new, borderless window the size of the screen and paint it black. This works great as long as my screensaver app is the current app, but if it's in the background, the black window appears BEHIND the windows of the current app, which makes it pretty useless as a screensaver. Calls to SelectWindow() and BringToFront() don't seem to work. Apparently something prevents an application running in the background from making one of its windows the front window. Any great ideas? I'm wondering how screensavers such as After Dark black out the screen. Any ideas or input on this topic would be appreciated. Thanks! Steve Chamberlin - slchambe@athena.mit.edu +++++++++++++++++++++++++++ From: bi341@cleveland.Freenet.Edu (Steve G. Crutchfield) Organization: Case Western Reserve University, Cleveland, Ohio, (USA) Date: Mon, 22 Jun 92 05:42:29 GMT The first method you mentioned is, I think, the best way to go about it. You can prevent other applications from drawing over your port by setting the global variable grayRgn to an empty region (of course you have to save it so you can restore it later). Then, use the obscure Window Manager routine CalcVisBehind, passing it a pointer to the frontmost window, and the OLD grayRgn. This makes sure the window manager knows that no drawing can take place in any windows. You can also prevent things like SuperClock from appearing by setting the global variable mBarHeight to 0. (You have to reset this one too, of course!) Hope this helps. Steve Crutchfield stevec@imsa.edu --------------------------- From: Josh.Adams@bbs.oit.unc.edu (Josh Adams) Subject: Offscreen PixMaps Date: 12 Jun 92 12:31:16 GMT Organization: Extended Bulletin Board Service What is the easiest way to have offscreen PixMaps? (yes, I thought awhile ago when I was asking about type-casting PixMaps that I was doing it, but I was wrong...) Anyway, I've heard something about gWorlds, but have not seen anything about them. I don't think they're in IM V, but they are in VI, which I don't have. If someone could tell me how to do offscreen PixMaps easily, I'd be very grateful... Thanks... Josh - -- The opinions expressed are not necessarily those of the University of North Carolina at Chapel Hill, the Campus Office for Information Technology, or the Experimental Bulletin Board Service. internet: bbs.oit.unc.edu or 152.2.22.80 +++++++++++++++++++++++++++ From: zobkiw@world.std.com (Joe Zobkiw) Date: 12 Jun 92 12:45:11 GMT Organization: The World Public Access UNIX, Brookline, MA To learn about offscreen pixmaps or bitmaps, read the technical note about them. I forget the number off the top of my head but 120 seems to stick in my mind. There are two notes, one on bitmaps, one of pixmaps. The code included in the notes is ALL YOU NEED to make it work. - -- - -- joe zobkiw Internet: zobkiw@world.std.com - -- AOL: AFL Zobkiw - -- mac.synthesis.MIDI.THINK C.OOP.asm CI$: 70712,515 - -- communications.networks.cool tunes... +++++++++++++++++++++++++++ From: vvann@umbio.med.miami.edu (Vince Vann) Organization: University of Miami Medical School Date: Fri, 12 Jun 1992 18:22:02 GMT Josh.Adams@bbs.oit.unc.edu (Josh Adams) writes: : What is the easiest way to have offscreen PixMaps? (yes, I thought awhile : ago when I was asking about type-casting PixMaps that I was doing it, : but I was wrong...) Anyway, I've heard something about gWorlds, but have : not seen anything about them. I don't think they're in IM V, but they are in : VI, which I don't have. If someone could tell me how to do offscreen PixMaps : easily, I'd be very grateful... : First, you should read the macintosh technical note #120 entitled "Principia Offscreen Graphics Environments". This covers everything you need to know about PixMaps, CGrafPorts, and GDevices, plus some info on 32-Bit QuickDraw GWorlds. Second, if you are using THINK C 5.02 and TCL, I have written two TCL classes that handle everything needed to setup an offscreen color graphics environment. If you are interested in these classes (CPixelWorld and CPixelWorldPane), please contact me via E-mail and I will send you the source. Note: I am currently revising the PixelWorld classes. As soon as I complete the revisions, I will submit the source to the <ftp.brown.edu> archive. I'll post a message to C.S.M.P as soon as they are available. Good luck, Vince - -- Vincent R. Vann University of Miami School of Medicine Miami, FL E-mail: vvann@umbio.med.miami.edu +++++++++++++++++++++++++++ From: gluttony@reed.edu!gluttony.reed.edu!pcalahan (Patrick John Calahan) Date: 16 Jun 92 19:56:17 GMT Organization: Reed College, Portland, OR I want to do drawings in offscreen pixmaps. I set everything up with NewPixMap(), and for the most part it works ok. BUT If I copybits to the pixmap and then to the screen, all non-white pixels are drawn on the screen in black. However, If I copybits the image directly to the screen, it looks fine. This suggests to me that I am setting one of the pixmap's fields incorrectly. (?) Can anyone send me some code which shows how to do this correctly? Mail to pcalahan@reed.edu or post here... Thanx in advance, Pat +++++++++++++++++++++++++++ From: Jeremiah.Blatz@dartmouth.edu (Jeremiah Blatz) Date: 24 Jun 92 05:23:45 GMT Organization: Dartmouth College, Hanover, NH In article <m0lxjdU-0006ChC@gluttony.reed.edu> gluttony@reed.edu!gluttony.reed.edu!pcalahan (Patrick John Calahan) writes: > If I copybits to the pixmap and then to the screen, all non-white pixels > are drawn on the screen in black. However, If I copybits the image > directly to the screen, it looks fine. This suggests to me that I am > setting one of the pixmap's fields incorrectly. (?) You could be setting thr "mode" field incorrectly, probably one of the "or" methods (srcOr (1) or notSrcOr (5)). For a standard copy, the transfer method is srcCopy (0). Hope this helps, Jeremiah _______________________________. /___ . _____. ___ __ ___ . / / / /____/ /__/ / / /__) / / __ / / _____/ ___/ / ___ / / \ \__/ / /____/ /\ \ / /__) / /___ \____/______/ / \_\ /______/_____/ jerbl@dartmouth.edu "When the world is running down, you make the best of what's still around." -Sting --------------------------- From: jrk@information-systems.east-anglia.ac.uk (Richard Kennaway) Subject: Apple Event problem Date: 12 Jun 92 22:00:25 GMT I recently upgraded an application to use Apple Events. Just the required set, i.e. open appl, open doc, print doc, and quit. I'm not very happy with the result. It's a text editor. Suppose I open it by double-clicking on a document it created, and then search for a string in that document. So I go, without a pause, click-click, command-F (to bring up its search dialog), type string, return. Previously, this would work. It would open the doc via GetAppFiles, then start processing events and find my keystrokes waiting for it. With Apple Events, however, I find that WaitNextEvent delivers my keystrokes before the Apple Event telling it to open a document. This is not good - I want to search for the string after the document is open. I have to wait until the window appears before I can do anything, and for no good reason. (BTW, contrary to the example program and recommendations way back in IM vol.1, I never call FlushEvents at startup, and for the same reason. It imposes an unnecessary wait on the user. And besides, dammit, when I type, the machine should listen!) I tried giving AppleEvents priority, by doing a WaitNextEvent( highLevelMask, ... ) and only if that returned false doing WaitNextEvent( everyEvent, ... ). It solved the problem but created worse ones. I got various unpleasant weirdness: losing some osEvts, behaving as if getFrontClicks was on, which it wasn't, etc., Since it currently has no use for any other Apple Events, I could just set it back to non-Sys7-aware, but I may want to do more exotic things with Apple Events in future. Is there a solution? BTW, what is the purpose of the "open application" Apple Event? Informing an application that it is open seems remarkably superfluous. Cogito ergo sum - if the app is in a position to wonder if it's running, it is. - -- Richard Kennaway SYS, University of East Anglia, Norwich NR4 7TJ, U.K. Internet: jrk@sys.uea.ac.uk uucp: ...mcsun!ukc!uea-sys!jrk +++++++++++++++++++++++++++ From: jackl@austin.apple.com (Jack Littleton) Date: Sat, 13 Jun 1992 18:09:17 GMT Organization: Apple Computer, Inc. In article <9705.9206122200@s4.sys.uea.ac.uk>, jrk@information-systems.east-anglia.ac.uk (Richard Kennaway) writes: > BTW, what is the purpose of the "open application" Apple Event? Informing > an application that it is open seems remarkably superfluous. Cogito ergo > sum - if the app is in a position to wonder if it's running, it is. I know this isn't the answer you were looking for (i.e. how to handle events after immediately opening your document -- sounds tough), but anyway... Only the Finder uses the open application event, and it is indeed sent after the application has been opened. What it is supplied for is for initialization code such as bringing up a empty, untitled window. It's simply a signal that your application was opened by the Finder. - -- Jack Littleton Developer Tools Engineering Group Apple Computer, Inc. +++++++++++++++++++++++++++ From: greeny@top.cis.syr.edu (J. S. Greenfield) Date: 13 Jun 92 21:17:45 GMT Organization: Syracuse University, CIS Dept. In article <9705.9206122200@s4.sys.uea.ac.uk> jrk@information-systems.east-anglia.ac.uk (Richard Kennaway) writes: >I recently upgraded an application to use Apple Events. Just the required >set, i.e. open appl, open doc, print doc, and quit. I'm not very happy >with the result. [...] >I tried giving AppleEvents priority, by doing a WaitNextEvent( >highLevelMask, ... ) and only if that returned false doing WaitNextEvent( >everyEvent, ... ). It solved the problem but created worse ones. I got >various unpleasant weirdness: losing some osEvts, behaving as if >getFrontClicks was on, which it wasn't, etc., [...] >Is there a solution? > >BTW, what is the purpose of the "open application" Apple Event? Informing >an application that it is open seems remarkably superfluous. Cogito ergo >sum - if the app is in a position to wonder if it's running, it is. I'd say it's there for a very good reason--and it is very much related to the solution to your problem. Because of the "open application" event, you know that no materr *how* your (apple-event aware) application is started, you will *always* receive an initial apple event after startup (either an 'oapp', an 'odoc', or a 'pdoc' event). Because of this, you can program your application to await *only* high-level events *until* the initial apple event arrives. (You shouldn't stop looking for apple events just because the first call to WaitNextEvent with the high-level event mask comes up with a null event.) So set your program to wait for the initial apple event, process it, and then process any other events that are waiting. That should make things work the way you want. - -- J. S. Greenfield greeny@top.cis.syr.edu (I like to put 'greeny' here, but my d*mn system wants a *real* name!) "What's the difference between an orange?" +++++++++++++++++++++++++++ From: grobbins@Apple.COM (Grobbins) Date: 14 Jun 92 09:38:57 GMT Organization: DTS, more or less In article <1992Jun13.171745.18868@newstand.syr.edu> greeny@top.cis.syr.edu writes: >Because of the "open application" event, >you know that no materr *how* your (apple-event aware) application is started, >you will *always* receive an initial apple event after startup (either an >'oapp', an 'odoc', or a 'pdoc' event). While this is presently true under normal circumstances, application code should still be written defensively: do not demand an Apple event after starting up, and do not depend on receiving one of those three. >Because of this, you can program your application to await *only* high-level >events *until* the initial apple event arrives. (You shouldn't stop looking >for apple events just because the first call to WaitNextEvent with the >high-level event mask comes up with a null event.) > >So set your program to wait for the initial apple event, process it, and then >process any other events that are waiting. That should make things work the >way you want. It is not a good idea to mask out everything. Always handle update events when they come in, and do remember that OS events are not queued, so if you are keeping track of being in the foreground or background by looking at suspend/resume events, then OS events should never be masked out. There is a way to "prefetch" Apple events via the GetSpecificHighLevelEvent call, but it's rather ugly and probably best avoided. See the Event Manager chapter of Inside Mac VI for documentation on this stuff. Grobbins grobbins@apple.com Usual disclaimers apply. +++++++++++++++++++++++++++ From: jpugh@apple.com (Jon Pugh) Date: 15 Jun 92 05:44:59 GMT Organization: Apple Computer, Inc. In article <1992Jun13.180917.12101@pcnntp.apple.com>, jackl@austin.apple.com (Jack Littleton) writes: > > In article <9705.9206122200@s4.sys.uea.ac.uk>, jrk@information-systems.east-anglia.ac.uk (Richard Kennaway) writes: > > BTW, what is the purpose of the "open application" Apple Event? Informing > > an application that it is open seems remarkably superfluous. Cogito ergo > > sum - if the app is in a position to wonder if it's running, it is. > > I know this isn't the answer you were looking for (i.e. how to handle events > after immediately opening your document -- sounds tough), but anyway... > > Only the Finder uses the open application event, and it is indeed sent after > the application has been opened. What it is supplied for is for > initialization code such as bringing up a empty, untitled window. It's > simply a signal that your application was opened by the Finder. I would like to add that if you launch and don't get an Open Application event, you should just go straight to your event loop without any fuss. This may be done to get you to launch in the background, like a daemon for example. This way you won't bother the user of the machine, who won't be looking for you, since you would've gotten an oapp, odoc or pdoc if he was looking at your program. Once again, no oapp, no new doc. Just go to the main event loop after initializing everything. You should be ready to do a new doc or whatever. Jon Pugh kAERegistrar +++++++++++++++++++++++++++ From: brady@cs.tcd.ie (Brady Michael) Organization: Trinity College, Dublin (Computer Science) Date: Mon, 15 Jun 1992 09:43:25 GMT In article <68674@apple.Apple.COM> grobbins@Apple.COM (Grobbins) writes: > >While this is presently true under normal circumstances, application >code should still be written defensively: do not demand an Apple >event after starting up, and do not depend on receiving one of those three. I'm looking for a little clarification on this: The way I have set up my application - Open Prolog - is this: after it starts up it looks for a pending high-level event, of type OAPP, ODOC or PDOC. If none of these are present, somewhere in the event queue, then the application presumes that it has been started in a non-HLE environment and goes on to getAppFiles, etc. Are you saying this is inadvisable? Mike - -- Michael Brady brady@cs.tcd.ie Department of Computer Science University of Dublin, Trinity College Dublin, Ireland +++++++++++++++++++++++++++ From: sstorkel@waimea.oracle.com (Scott Storkel) Organization: Oracle Corporation, Belmont, CA Date: Mon, 15 Jun 1992 18:12:47 GMT In article <1992Jun15.094325.6324@cs.tcd.ie> brady@cs.tcd.ie (Brady Michael) writes: >I'm looking for a little clarification on this: >The way I have set up my application - Open Prolog - is this: after it starts up >it looks for a pending high-level event, of type OAPP, ODOC or PDOC. If >none of these are present, somewhere in the event queue, then the >application presumes that it has been started in a non-HLE environment >and goes on to getAppFiles, etc. >Are you saying this is inadvisable? Okay, here's what I'd do. I think this is correct, but somebody from Apple can point me down the right path if I've strayed... 1. Initialize everything. This includes all of the Toolbox managers as well as application initialization code. 2. Call Gestalt and see if the Apple Event Manager is present. If yes, goto 4. 3. AE Manager isn't available, so open/print files using CountAppFiles(), GetAppFiles(), etc. Create an "untitled" document if you would normally do so in response to an oapp Apple Event. 4. Enter your main event loop! Be sure to handle the oapp, odoc, and pdoc Apple Events. If you get odoc or pdoc events, open or print the corresponding files. If you get an oapp event, open an "untitled" document or perform any other user visible actions that should happen when your program is launched. It's important to note that #4 should be your real, live, handle-everything main event-loop. Any questions? -- Scott ============================================================================== Code Warrior 500 Oracle Parkway Advanced Products Division Box 659405 Oracle Corporation Redwood Shores, CA. 94065 415-506-2493 FAX: 415-506-7216 ============================================================================== - -- ============================================================================== Code Warrior 500 Oracle Parkway Advanced Products Division Box 659405 Oracle Corporation Redwood Shores, CA. 94065 415-506-2493 FAX: 415-506-7216 ============================================================================== +++++++++++++++++++++++++++ From: baugh@voyager.east.isx.com (Earl Baugh) Date: 16 Jun 92 20:34:38 GMT Organization: ISX Corporation, East Coast Office In article <1992Jun13.180917.12101@pcnntp.apple.com> jackl@austin.apple.com (Jack Littleton) writes: >In article <9705.9206122200@s4.sys.uea.ac.uk>, jrk@information-systems.east-anglia.ac.uk (Richard Kennaway) writes: >> BTW, what is the purpose of the "open application" Apple Event? Informing >> an application that it is open seems remarkably superfluous. Cogito ergo >> sum - if the app is in a position to wonder if it's running, it is. > >Only the Finder uses the open application event, and it is indeed sent after >the application has been opened. Sorry to say, that's not the only way an application gets an Open Application Event. Any application that uses LaunchApplication to launch your application can cause it to get an Open Application event. (We won't discuss how badly the LaunchApplication call is documented.....) BTW, your application can get just about any event from the Launching program, open document comes to mind... 'later - -- Earl D. Baugh Jr. ISX Corporation Internet : baugh@voyager.east.isx.com +++++++++++++++++++++++++++ From: jpugh@apple.com (Jon Pugh) Date: 26 Jun 92 04:35:46 GMT Organization: Apple Computer, Inc. In article <1992Jun15.094325.6324@cs.tcd.ie>, brady@cs.tcd.ie (Brady Michael) writes: > > The way I have set up my application - Open Prolog - is this: after it starts up > it looks for a pending high-level event, of type OAPP, ODOC or PDOC. If > none of these are present, somewhere in the event queue, then the > application presumes that it has been started in a non-HLE environment > and goes on to getAppFiles, etc. > Are you saying this is inadvisable? Yes, this is inadvisable. Call Gestalt and see if the AE manager is available. If you have the SIZE resource's highLevelEventAware bit then you will get an AE and you can just relax, initialize and idle, dealing with whatever you get or don't get when you do or don't get it, as you should. If the AEM is not available, check the appFiles. Jon kAERegistrar --------------------------- From: jstevens@crick.ssctr.bcm.tmc.edu (Jason Philip Stevens) Subject: Getting the text from a TERec Date: 15 Jun 1992 17:46:56 GMT Organization: Baylor College of Medicine, Houston, Tx I'm trying to extract the text from a TERec into a standard C-style char* . Suppose I have a TERec**, TEHandle. Accoring to IM-1, p377, the hText member is a "handle to the text to be edited." if I try *(*TEHandle)->hText, I get garbage. If I try to use the TEGetText routine, I get a CharsHandle returned (a handle to a packed array of chars). If I dereference that, I also get garbage. How do I actually get my hands on a char*? BTW, I've tried using PtoCstr, on the assumption that the resultant string would be in Pascal format, and while it compiles, in use it generates a bus error... Thanks for any help... - -jps - -- Jason Stevens Internet: jstevens@bcm.tmc.edu Network User Services Voice: (713) 798-7370 Baylor College of Medicine Opinions expressed are mine alone. +++++++++++++++++++++++++++ From: zobkiw@world.std.com (Joe Zobkiw) Organization: The World Public Access UNIX, Brookline, MA Date: Tue, 16 Jun 1992 01:03:28 GMT In article <12523@gazette.bcm.tmc.edu> jstevens@crick.ssctr.bcm.tmc.edu (Jason Philip Stevens) writes: > >I'm trying to extract the text from a TERec into a standard C-style >char* . Suppose I have a TERec**, TEHandle. > Well, first of all, if your TERec contains more than 255 characters of text you may bomb when you try to cast it as a Str255. However, if you want to do this you can use something like: void TE2Str(TEHandle te, Str255 str) { GetIText((te)->hText, str); } void Str2TE(Str255 str, TEHandle te) { TESetText((Ptr)&str[1], (long)str[0], te); } This might also help you with your other problem, finding the text. Remember, hText is a _Handle_ to the text in question. Two dereferences of a Handle get you to it's data. - -- - -- joe zobkiw Internet: zobkiw@world.std.com - -- AOL: AFL Zobkiw - -- mac.synthesis.MIDI.THINK C.OOP - -- asm.comm.networks.cool tunes... +++++++++++++++++++++++++++ From: lari@bach.cs.unc.edu (Humayun Lari) Date: 16 Jun 92 18:12:33 GMT Organization: University of North Carolina, Chapel Hill In article <Bpwyxu.1n6@world.std.com> zobkiw@world.std.com (Joe Zobkiw) writes: >In article <12523@gazette.bcm.tmc.edu> jstevens@crick.ssctr.bcm.tmc.edu (Jason Philip Stevens) writes: >> >>I'm trying to extract the text from a TERec into a standard C-style >>char* . Suppose I have a TERec**, TEHandle. >> > >Well, first of all, if your TERec contains more than 255 characters of text >you may bomb when you try to cast it as a Str255. However, if you want to do >this you can use something like: > >void TE2Str(TEHandle te, Str255 str) >{ > GetIText((te)->hText, str); >} Um, isn't GetIText only for dialogs? Perhaps this might be a bit better: OSErr TE2CStr(TEHandle te, char *str) { short textLength; textLength = (**te).teLength; str = (char *)NewPtr(textLength + 1); if (MemError() != noErr) return MemError(); BlockMove( (Ptr)(*TEGetText(te)), (Ptr)str, textLength); str[textLength] = '\0'; return noErr; } Since you're using C, this should work OK no matter how much text the TERec contains (up to the 32K limit). Anyone see a silly mistake? (My C's kind of rusty.) > >void Str2TE(Str255 str, TEHandle te) >{ > TESetText((Ptr)&str[1], (long)str[0], te); >} void CStr2TE(char *str, TEHandle te) { TESetText((Ptr)str, strlen(str), te); } > >This might also help you with your other problem, finding the text. >Remember, hText is a _Handle_ to the text in question. Two dereferences >of a Handle get you to it's data. After years and years, I still forget... :-) Humayun Lari (lari@cs.unc.edu) +++++++++++++++++++++++++++ From: ewylie@ocf.berkeley.edu (Elizabeth Wylie) Date: 17 Jun 92 04:26:05 GMT Organization: U.C. Berkeley Open Computing Facility > >void TE2Str(TEHandle te, Str255 str) >{ > GetIText((te)->hText, > str); >} > > Um, isn't GetIText only for dialogs? Perhaps this might be a bit > better: I noticed the GetIText call as well, but thought about it and had to smile. ":-)" When you perform a GetDItem on an edit text in a dialog, you get a handle to the text of the item. GetIText just copies at most 255 bytes of this handle into a pascal string. So long as it is passed a handle to text, you're OK. vrey nice. - -Elizabeth +++++++++++++++++++++++++++ From: zobkiw@world.std.com (Joe Zobkiw) Date: 17 Jun 92 10:46:38 GMT Organization: The World Public Access UNIX, Brookline, MA The GetIText 'trick' came from THINK Reference. I will not take credit for it. I just found it to be an easy to understand way of doing things :) - -- - -- joe zobkiw Internet: zobkiw@world.std.com - -- AOL: AFL Zobkiw - -- mac.synthesis.MIDI.THINK C.OOP - -- asm.comm.networks.cool tunes... +++++++++++++++++++++++++++ Date: 24 Jun 92 19:33:49 GMT From: jopa@tkk.tele.fi (Jorma Paananen) lari@bach.cs.unc.edu (Humayun Lari) writes: > void CStr2TE(char *str, TEHandle te) > { > TESetText((Ptr)str, strlen(str), te); > } >From IM I-383: "TESetText doesn't dispose of any text currently in the edit record" What is the correct way to free old text ? Jorma jopa@tkk.tele.fi +++++++++++++++++++++++++++ From: lari@bach.cs.unc.edu (Humayun Lari) Date: 25 Jun 92 20:52:29 GMT Organization: University of North Carolina, Chapel Hill In article <jopa.709414429@tkk.tele.fi> jopa@tkk.tele.fi (Jorma Paananen) writes: >lari@bach.cs.unc.edu (Humayun Lari) writes: >> void CStr2TE(char *str, TEHandle te) >> { >> TESetText((Ptr)str, strlen(str), te); >> } > >From IM I-383: > "TESetText doesn't dispose of any text currently in the edit record" > >What is the correct way to free old text ? Well, I *did* have a feeling that it couldn't be that simple :-). Maybe this will work: (Anyone see more amazingly silly mistakes?) void CStr2TE(char *str, TEHandle te) { TESetSelect(0, 32767, te); /* IM I-385 */ TEDelete(te); /* IM I-387 */ TESetText((Ptr)str, strlen(str), te); } Note that the edit record should be inactive, or else the selection will be highlighted. If the string is long, you might prefer to use TEGetText to access the text handle directly, so you can check for memory errors when resizing the handle to fit. Humayun Lari (lari@cs.unc.edu) ObSig: "Technology changes rapidly; people and meaning do not." -- Kevin Bjorke --------------------------- End of C.S.M.P. Digest **********************